So far, the traffic generated in mobile networks such as e.g. GERAN, UTMS Radio Access Network (UTRAN) has mostly been dominated by services that require human interaction, such as e.g. regular speech calls, web-surfing, sending Multimedia Messaging Service (MMS), doing video-chats etc. The same traffic pattern is also anticipated for Evolved UTMS Radio Access Network (E-UTRAN). As a natural consequence, these networks are designed and optimized primarily for these “Human Type Communication” (HTC) services.
There is however an ever-increasing market segment of Machine Type Communication (MTC) services, which does not necessarily need human interaction. MTC devices support a very diverse flora of applications such as e.g. vehicle applications (automatic emergency calls, remote diagnostics and telematics, vehicle tracking etc.), gas- and power-meter applications as well as network surveillance and camera applications. The requirements these services puts on the serving network will thus without any doubt significantly differ from what is provided by today's HTC-optimized mobile networks, as outlined in Third Generation Partnership Program (3GPP) Technical Specification TS 22.368. The amount of these MTC and HTC devices could reach a total of near 50 billion in the year 2020. Thus, for mobile networks such as GERAN to be competitive for these mass market MTC applications and devices, it is important to optimize their support for machine-type communications.
At the same time the market penetration by the so called smartphones is very aggressively increasing. One typical smart phone characteristics is to issue small data transfers e.g. to keep the firewall protecting the 3GPP network opened. These short transactions consume many identifiers while requiring low bandwidth. This may easily result in “identifier depletion” as well as “under-utilization” of the actual radio resources. To overcome this problem more identifiers are needed so that a larger number of such transactions can be multiplexed on shared radio resources.
Currently for GERAN, each Temporary Block Flow (TBF) is assigned a Temporary Flow Identity (TFI) value by the network. This value is unique among concurrent TBFs in the same direction (uplink or downlink) on all Packet Data Channels (PDCHs) used for the TBF. The same TFI value may be used concurrently for other TBFs on other Packet Data Channels (PDCHs) in the same direction and for TBFs in the opposite direction. Hence a TFI is a unique identifier on a given resource (PDCH). This limits the number of concurrent TBFs and thus limits the number of devices that may share the same radio resources to the number of existing TFIs.
The existing TFI itself is a 5-bit field encoded as binary number in the range 0 to 31, which is typically provided to the Mobile Station (MS) by the GERAN network upon assignment.
An Radio Link Control/Medium Access Control (RLC/MAC) block associated with a certain TBF is thus identified by the TFI together with, in case of a RLC data block, the direction (uplink or downlink) in which the RLC data block is sent; and in case of a RLC/MAC control message, the direction in which the RLC/MAC control message is sent and the message type. In case of Starting Sequence Number (SSN)-based Fast Ack/Nack Reporting (FANR) is used, then the TFI identifying the TBF being acknowledged is included in the Piggy-backed Ack/Nack (PAN) field.
This means that e.g. every time an MS receives a downlink data or control block, it will use the included TFI field to determine if this block belongs to any (there can be more than one) of the TBFs associated with that very MS. If so, the block is obviously intended for this MS whereupon the corresponding payload is decoded and delivered to upper layers, but otherwise discarded. In the uplink direction, the behavior is the same, i.e. network uses the TFI value to identify blocks that belong to the same TBF.
It can be noted that the TFI for the RLC data block(s) and the TFI for the PAN can be addressed to different TBFs and thus different MSs.
The existing TFI addressing space can be insufficient assuming the increase of MTC and smartphone driven transactions. As the Piggy Backed Ack/Nack (PAN) field that can be included in the RLC/MAC data block can be addressed to another receiver than the actual RLC/MAC data block, the overall challenge is twofold:                increase the TFI addressing space for addressing the RLC/MAC data block receiver.        increase the TFI addressing space for addressing the PAN receiver.        